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Abstract — In a commercially hosted operational mode, a 
scientific instrument or operational device is attached to a 
spacecraft but operates independently from the spacecraft’s 
primary mission. Despite the expected benefits of this 
arrangement, there are few examples of hosted payload 
programs actually being executed by government 
organizations. The lack of hosted payload programs is 
largely driven by programmatic challenges, both real and 
perceived, rather than by technical challenges. Partly for 
these reasons, NASA has not sponsored a hosted payload 
program, in spite of the benefits and visible community 
interest in doing so. In the interest of increasing the use of 
hosted payloads across the space community, this paper 
seeks to alleviate concerns about hosted payloads by 
identifying these programmatic challenges and presenting 
ways in which they can be avoided or mitigated. 

Despite the challenges, several recent hosted payload 
programs have been successfully completed or are currently 
in progress. This paper presents an assessment of these 
programs, with a focus on acquisition, costs, schedules, 
risks, and other programmatic aspects. The hosted payloads 
included in this study are the Federal Aviation 
Administration’s Wide Area Augmentation System 
(WAAS) payloads, United States Coast Guard’s Automatic 
Identification System (AIS) demonstration payload, 
Department of Defense’s IP Router In Space (IRIS) 
demonstration payload, the United States Air Force’s 
Commercially Hosted Infrared Payload (CHIRP), and the 
Australian Defence Force’s Ultra High Frequency (UHF) 
payload. General descriptions of each of these programs are 
presented along with issues that have been encountered and 
lessons learned from those experiences. 

A set of recommended approaches for future hosted payload 
programs is presented, with a focus on addressing risks or 
potential problem areas through smart and flexible 
contracting up front. This set of lessons and 

recommendations is broadly applicable to future hosted 
payload programs, whether they are technology 
demonstrations, communications systems, or operational 
sensors. Additionally, we present a basic cost model for 
commercial access to space for hosted payloads as a 
function of payload mass. 12 
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1. Introduction 

In 1966, NASA’s ATS-1 communication satellite carried 
meteorological sensors unrelated to its primary payload into 
space. The idea of using excess capacity on satellites to 
carry additional payloads has been considered since the 
inception of the industry. Due to their inherent cost and 
schedule benefits, commercially hosted payloads represent a 
significant opportunity for NASA and other government 
entities to fly science payloads and technology 
demonstration missions on orbit. 

While not a new concept, hosted payloads have yet to be 
utilized by NASA or utilized extensively by the United 
States Government (USG). The limited use to date is due to 
both the perceived risks and the programmatic challenges 
associated with this new method of launching payloads. 
This paper summarizes a study of recent hosted payload 
programs with the intent to address the perception of risk 
associated with hosted payloads. It is intended that this 
study will provide the factual basis to increase access to 
space for suitable payloads using commercial hosting. 

Definitions 

In the context of this document, the term hosted payload 
refers specifically to a government payload that is launched 
to orbit as a secondary payload on a commercial host 
spacecraft. The host spacecraft provides resources to the 
payload such as structure, pointing, power, and 
communications. For the purposes of this paper, a hosted 
payload is not a second spacecraft on a shared launch; it is 
not a small satellite; it is not a suborbital payload; and it is 
not a secondary payload hosted on a government spacecraft. 
The hosted payloads can be technology demonstrations, 
research equipment, flight qualification units, or fully 
operational sensors or systems. 
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When referenced in this document, the customer is the 
government organization that is contracting to find a host 
spacecraft to take their payload or capability to orbit. The 
satellite owner is the commercial entity that owns the host 
spacecraft on orbit. Generally, the owner is also the same 
entity as the satellite operator , who is responsible for on- 
orbit and ground operations throughout the satellite’s 
lifetime. The spacecraft provider is the contractor that is 
responsible for manufacturing the satellite bus and the 
primary commercial payloads. The payload provider is the 
contractor that is responsible for developing and building 
the hosted payload itself. In some cases, the spacecraft and 
payload providers are the same contractor. The system 
integrator is responsible for integrating the hosted payload 
and spacecraft and is often the same as either the spacecraft 
provider or the payload provider. In some cases the system 
integrator is also responsible for subcontracting the hosting 
opportunity. 

Motivation 

The primary goal of the study that led to this paper is to 
examine the experiences of government agencies with 
hosted payloads and to identify the lessons learned. This 
goal is addressed through the identification of successful 
approaches for implementing hosted payloads on 
commercial communications satellites. The hosted payload 
option is not viable for all NASA payloads, but it is 
appropriate for meeting a select subset of USG needs. 
Additional goals include satisfying the 2010 National Space 
Policy and create new opportunities to meet the desire for 
low-cost science missions to Geostationary Earth Orbit 
(GEO) that would not be feasible under current mechanisms 
and funding. It should be noted that hosted payloads can 
also be hosted on commercial spacecraft in Low Earth Orbit 
(LEO). The commercial satellite market in GEO is larger 
than the commercial LEO market and affords more frequent 
opportunities for hosting. 

Cost Overruns and Schedule Growth — USG space programs 
often experience significant cost and schedule overruns. 
Four examples of cost overruns, shown in Figure 1, are the 
Advanced Extremely High Frequency (AEHF) program, the 
National Polar-orbiting Operational Environmental Satellite 
System (NPOESS), Space Based Infrared System (SBIRS), 
and Global Positioning System (GPS). As can be seen in 
Figure 1, NPOESS has doubled in cost since its inception 
and SBIRS costs are nearly three times the original estimate. 

Program schedules grow similarly, resulting in capabilities 
arriving on orbit many years beyond their target date. The 
capabilities are therefore often out of date by the time they 
become operational. Additionally, any replacement 
capability is often delayed, requiring the on-orbit capability 
to remain operational long past its expected lifetime. 

Hosted payloads provide an innovative solution to cost and 
schedule overruns. The hosted payload program schedule is 


inherently constrained to the schedule of the satellite owner, 
as will be discussed in more detail later. The constrained 
schedule does not allow for delays in the development of the 
hosted payload, in order for the payload to be integrated and 
tested in time for the launch. Since the schedule cannot 
generally be adjusted, there can be little allowance for creep 
in the payload capabilities/requirements. The limit on 
requirements creep helps reduce the potential for cost 
overruns. 



AEHF NPOESS SBIRS GPS 


Figure 1: Program Cost Growth From Initial 
Estimate[l] 

Image used with permission from SMC/XR 

2010 National Space Policy — The 2010 National Space 
Policy, released on June 28, 2010, drives USG towards the 
hosted payload option in two ways. First, it specifically 
directs that agencies “Work jointly to acquire space launch 
services and hosted payload arrangements that are reliable, 
responsive to United States Government needs, and cost- 
effective.” Additionally, the policy states that agencies 
should “Actively explore the use of inventive, nontraditional 
arrangements for acquiring commercial space goods and 
services to meet United States Government requirements, 
including measures such as... hosting government 

capabilities on commercial spacecraft.”[2] 

Second, the National Space Policy includes several areas 
that can be addressed in part through a hosted payload 
program, including providing cost-effective assured access 
to space, “Develop and Retain Space Professionals” to 
support Science, Technology, Engineering, and 
Mathematics (STEM) initiatives, “Strengthen Interagency 
Partnerships,” provide for “Potential International 
Cooperation,” and “promote a robust domestic commercial 
space industry.” [2] Each of these areas is addressed through 
the natural benefits of the hosted payload option, as will be 
discussed later. 

Interest in hosted payloads for NASA science missions — In 
the last 1 5 years, over a dozen hosted payload missions have 
been proposed to NASA solicitations, but none has been 
funded by NASA to date. Two of these examples, the 
Geostationary Observatory for Tropospheric Air Chemistry 
(GeoTRACE) and the Global-scale Observations of the 
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Limb and Disk (GOLD) received high ratings during their 
reviews, but were not funded by NASA selection officials. 
GeoTRACE was proposed to the Earth Science New 
Millennium Program in 1999 by a team under Principal 
Investigator (PI) Dr. Jack Fishman from Langley Research 
Center. GeoTRACE was funded to develop a Step 2 
proposal, which received “outstanding” ratings in all 
evaluation criteria. GOLD was proposed to the Space 
Science Small Explorers (SMEX) Step 1 in 2007 and was 
funded to develop a Step 2 Concept Study Report, but was 
not selected following the Step 2 review in 2008. The 
GOLD team was led by PI Dr. Richard Eastes of the 
University of Central Florida. Other proposed hosted 
payloads include GeoTROPSAT (1996), GeoExpress 
(1998), VOLCAM (1998), SEI-1 (1999), ESEI (2001), LMI 
(2001), GeoTrace-2 (2001), GIFTS (2003), MISTI (2005), 
TIGRIS (2005), GeoDBSim (2007), EAGLES (2007), 
TIGRIS-2 (2008). [3] 

Commercial interest in hosting government payloads — 
Although USG has so far only pursued commercially hosted 
payloads in a limited way, commercial satellite owners are 
generally interested in hosting USG payloads. The 
commercial owners have had positive experiences with 
several USG organizations and see benefits to hosting 
payloads. The growing interest in hosted payloads can be 
seen in part through the increasing number of hosted 
payload panel sessions at conferences such as the “Hosted 
Payloads: A New Model for Commercial/Military 

Cooperation” panel at SATELLITE 2010 and the “Hosted 
Payloads: Challenges in Meeting Commercial and 

Government Needs” panel at the Content and 
Communications World Expo in 2010. 

Commercial interest can also be seen in the participation of 
high level personnel (industry Vice Presidents, Directors, 
etc.) in the Inter-agency Hosted Payload Working Group. 
The working group is an ongoing set of working meetings 
led by the National Space Security Office (NSSO) to 
address the procurement, legal, and acquisition issues 
associated with hosted payloads. Many of the commercial 
operators have personnel specifically tasked to work on 
hosted payloads. 


Commercial owners are actively seeking new opportunities 
to host payloads, including remote sensing payloads. 
Research journals such as Science have recently carried 
advertisements for hosted payload services. 

Benefits of Hosted Payloads 

Financial Benefits — There are clear financial benefits from 
hosted payloads for both USG and the commercial 
companies involved. When procuring a new commercial 
satellite, the satellite owner invests a large amount of money 
up front to fund the build and launch of the spacecraft. 
Since they do not make any of this money back until the 
spacecraft is on orbit and operational, there is a strong 
incentive to keep the schedule short. Hosting a payload 
offers an opportunity for the owner to offset some of those 
initial costs by providing accommodation for a secondary 
payload on their spacecraft. There is an associated 
reduction in total spacecraft lifetime, because the payload 
mass offsets stationkeeping propellant. However, the small 
loss of revenue 10-15 years in the future is more than offset 
by the present value of the payments that are received for 
the hosted payload accommodations prior to launch. 

For USG, the low-cost access to space is a primary benefit, 
compared to the cost of developing a dedicated spacecraft 
and paying for its launch. The payload development costs 
are the same in either case, but the government program will 
only pay a small fraction of the spacecraft development and 
launch costs for accommodation on the commercial host. 
The highly modular commercial spacecraft buses minimize 
non-recurring engineering costs. The short schedule 
associated with hosted payloads, which constrains personnel 
costs to a few years, further reducing the cost to a USG 
hosted payload program. 

Schedule Benefits — The reduced schedule of a hosted 
payload compared to a standard NASA spacecraft 
development is a benefit in and of itself. A hosted payload 
program could last roughly 3-4 years from concept to 
launch, compared to normal programs lasting 5-10 years or 
more. The short schedules allow more opportunities for 
hosting USG payloads than can be provided by large, multi- 
sensor satellite development programs. Beyond the 
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potential to launch more payloads, this hosting approach 
allows for more technology development cycles in a fixed 
amount of time. Increasing the pace of technology 
development cycles may result in quicker maturation of 
technologies and can enable technological breakthroughs 
that would otherwise never leave the laboratory or drawing 
board. 

An example of a commercial spacecraft development 
schedule is shown in Figure 2, lasting approximately 30 
months from the spacecraft Request For Proposal (RFP) to 
launch. This schedule is much faster than typical USG 
development programs. In order to utilize this process, the 
USG customer should start coordinating with the satellite 
owner in the 18 months prior to the owner’s RFP for a 
spacecraft. Successful coordination could enable the hosted 
payload accommodations to be included in the spacecraft 
RFP. Inclusion in the owner’s RFP may make integration 
of the hosted payload fit more easily into the existing 
commercial processes. To meet the commercial schedule, it 
is preferred that the hosted payload be delivered for 
integration and test (I&T) 12 months before the planned 
launch date. 

The 2010 National Space Policy — Many aspects of hosted 
payloads specifically address areas defined in the National 
Space Policy. For example, commercial spacecraft provide 
“Assured Access to Space” because of the steady and 
continuous launch of spacecraft to almost all regions of 
GEO. On average, commercial owners together launch over 
20 GEO spacecraft per year, each of which is an opportunity 
for a hosted payload. These spacecraft operate at the 
locations shown in Figure 3 providing opportunities for 
payloads over the entire globe (except for a small region 
over the Pacific Ocean). It may be noted that many 
commercial companies keep a similar image indicating their 
spacecraft locations updated and available online. 



Figure 3: Global GEO communications satellite 
locations. [4] 

Image used with permission from Analytical Graphics, Inc. 


The specific dates associated with specific launch 
opportunities must be gathered by the customer or system 
integrator, as there is not currently a publicly-available 


central repository for upcoming launch information. The 
customer can ensure that the payload arrives at a useful 
orbital slot, if that is a mission constraint, by working with 
multiple spacecraft owners across the industry during the 
development of the mission concept. Although industry is 
interested in hosting USG payloads, it will only do so if the 
business case closes for the specific spacecraft being 
considered. This primary commercial mission may limit the 
payloads that can be hosted on a particular satellite. 

The National Space Policy also seeks to “promote a robust 
domestic commercial space industry.” Hosted payloads 
offer a direct way to strengthen the commercial industry. 
By offsetting the up-front investment by commercial 
owners, hosting allows the industry to operate with reduced 
risk. The arrangements also take advantage of existing 
capacity in the existing commercial infrastructure, which 
includes the spacecraft, launch vehicles, and ground 
systems. The inherent strength of the commercial satellite 
industry has enabled it to pass through the recent global 
recession with little impact. Beyond the commercial 
industry, hosted payloads also offer opportunities for inter- 
agency and international cooperation. 

Supporting Science, Technology, Engineering, and 
Mathematics (STEM) Initiatives — Hosted payloads may 
appear attractive to students and young professionals in the 
aerospace industry and other STEM fields. The hosted 
payload schedule is relatively short and offers more 
opportunities for practical hands-on experience to train 
systems engineers, principal investigators, and program 
managers. Hosted payloads may also help retain a highly 
qualified workforce by providing opportunities to work on 
multiple missions over a decade, rather than a single project. 

Challenges of Hosted Payloads 

One of the largest challenges facing hosted payloads lies in 
aligning the way USG and commercial industry operate. 
This alignment includes agreeing to a schedule that satisfies 
the needs of all parties and, just as importantly, keeping to 
the agreed-upon schedule. There are also procurement and 
legal matters that must be addressed to allow easier use of 
hosted payloads as a means for USG and industry to work 
together. 

Across the USG, some institutional resistance to using this 
new method of launching payloads exists. In part, this 
resistance is driven by the perceived risks associated with 
the non-standard way of contracting, procuring, and meeting 
standards for quality assurance and mission assurance. 

As previously stated, the rapid commercial schedule 
provides some benefits to the USG customer. However, it 
represents a challenge for the customer to design and 
develop a payload, conduct the appropriate reviews, 
compete and contract for the hosting accommodations on a 
timetable that aligns with the commercial schedule. For 
instance, the NASA Announcement of Opportunity (AO) 
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process can include multiple rounds of reviews and take 
over a year to select science missions to fund. Developing a 
hosted payload mission through this mechanism is 
challenging because the hosting opportunities must be 
identified far enough in advance to allow time for the 
review process, selection, payload development, integration, 
and testing prior to the desired host spacecraft’s launch date. 
Planning and coordination between the customer and 
industry with different schedules will require some 
adjustments on both sides. Alternatively, a new method of 
contracting this type of mission may be desired, 
incorporating the lessons learned from past programs 
presented later in this paper. 

Quality and mission assurance are also areas where the USG 
customer may need to alter its practices somewhat for a 
hosted payload program. The schedule of such a program 
may not allow time for the full set of development review 
cycles, which may require the customer to accept insight 
into the commercial quality assurance processes rather than 
normal level of oversight. Commercial owners are 
generally risk averse and have a high level of quality 
assurance processes. It may be beneficial to treat the 
purchase of accommodations on the host spacecraft as a 
commercial purchase, rather than a development contract. 

Recent hosted payload programs have generated lessons for 
potential issues and mitigations to address in the 
commercial contracts to avoid change orders and 
renegotiations later in the program. 

Uncertainty in the payment process may arise from USG 
budgetary processes, including delayed appropriations and 
congressional continuing resolutions. 

Study Objectives 

As stated previously, the main goal of this study is to 
provide sufficient information to enable the use of 
commercially hosted payloads within NASA programs. 
This goal is addressed by identifying successful approaches 
for hosting payloads on commercial satellites and examining 
the perceived risk of commercial access to space. The study 
team investigated five recent instances of commercially 


hosted government payloads, with a focus on the 
programmatic and procurement aspects of the programs. 

The investigation of these programs consisted of contacting 
the personnel involved to obtain information about how the 
programs were initiated and operated, how contracting and 
procurement issues were handled, what issues arose, and 
what lessons were learned during the program. In addition, 
the team also made contact with individuals at several 
satellite owner/operators and manufacturers to discuss 
potential approaches for future hosted payload programs. 

The final goal of the study was to develop a cost estimation 
model based on actual commercial contracts. This model 
can be used to estimate costs and payment schedules for 
future hosted payload programs. 

2. Recent Hosted Payload Programs 

The five recent hosted payload programs chosen for study 
are: 

• Wide Area Augmentation System (WAAS) - The 
Federal Aviation Administration (FA A) satellite-based 
navigation program, which uses an L-band payload to 
improve the accuracy of GPS signals for aircraft 
navigation and landing 

• Automatic Identification System (AIS) - The United 
States Coast Guard (USCG) demonstration mission for 
the AIS receiver/transmitter, which is used to identify 
ships up to 2000 nautical miles off the US coast. 

• Internet Router In Space (IRIS) - A Department of 
Defense (DoD) funded concept demonstration of 
Internet Protocol (IP) routing from GEO to improve 
global communications capability and flexibility. 

• Commercially Hosted Infrared Payload (CHIRP) - 
Demonstration by the United States Air Force (USAF) 
Space and Missile Systems Center (SMC) of an infrared 
(IR) staring sensor from GEO, providing risk reduction 
for future missile warning systems 

• Australian Defence Force (ADF) Ultra High Frequency 
(UHF) payload - The ADF originally sought to purchase 
a portion of a UHF payload to improve their 
communications capability. Currently, they are 


Table 1: Comparison of Recent Hosted Payload Programs 


Payload 

Payload Type 

Customer 

Owner/ 

Operator 

Spacecraft 

Provider 

Payload 

Provider 

Launch 

Vehicle 

Launch Date 

WAAS 

L-band comm 

FAA 

Telesat 

Intelsat 

EADS Astrium 
Orbital 

Lockheed 

Martin 

Proton 
Ariane V 

Sept, 2005 
Oct, 2005 

AIS 

VHF comm 

USCG 

Orbcomm 

Polyot 

Orbital 

Cosmos 

June, 2008 

IRIS 

IP Router 

DoD 

Intelsat 

SS/Loral 

Cisco 

Atlas V 

Nov, 2009 

CHIRP 

IRSensor 

USAF SMC 

AGS 

Orbital 

SAIC 

Ariane 

Q3, 2011 

ADF UHF 

UHF comm 

ADF 

Intelsat 

Boeing 

Boeing 

Proton 

June, 2012 


5 



purchasing the entire UHF payload, which is 
approximately 20% of total spacecraft payload. Such a 
large payload nearly moves this program out of the 
realm of hosted payloads. 

Table 1 summarizes high level programmatic characteristics 
of these five programs, including the primary companies 
and government agencies involved, with the primary 
contractor highlighted in bold text. Table 2 displays basic 
information about the hosted payload itself for each of the 
programs. A notional NASA science payload would fit well 
within the ranges indicated in Table 2 for mass, power, 
volume, and data rate. 


Table 2: Payload Characteristics 


Payload 

Mass 

(kg) 

Power 

(W) 

Volume 

(m 3 ) 

Customer Data 
Rate (bps) 

Payload Type 

WAAS 

60 

300 

1 

10M 

L-band comm 








AIS 

3 

8 

0.003 

10k 

VHF comm 

IRIS 

90 

450 

0.127 

60M 

IP Router 

CHIRP 

115 

275 

0.3 

70M 

IRSensor 

ADFUHF 

450 

2000 

8 

4k 

UHF comm 


Each of these programs provides its own set of lessons 
regarding potential issues to mitigate and each program will 
be described in detail in the following sections. 

WAAS: Wide Area Augmentation System 

WAAS is a FAA program that uses two L-band payloads on 
two satellites to enhance the accuracy of GPS signals for 
improved aircraft navigation and safety. The portion of 
WAAS specifically associated with the hosted payloads is 
referred to as the Geostationary Communications and 
Control Segment (GCCS). Prior to the launch of the two 
hosted payloads in 2005, WAAS was operated through 
leased L-band payload services on existing commercial 
satellites. The current WAAS/GCCS system has been used 
to improve air traffic management and increase airport 
throughput since the launch of both host spacecraft in 2005. 

The current WAAS system consists of 25 ground stations, a 
set of GEO Uplink Stations (GUSs), and the two hosted 
payloads on the Galaxy 15 and Anik FIR spacecraft. The 
ground stations receive GPS signals, check them for errors, 
and then distribute GPS signal corrections. The signal 
corrections are distributed via the WAAS ground network 
and transmitted by the GUSs to the on-orbit payloads. The 
hosted payloads subsequently broadcast the GPS correction 
signals to dedicated receivers onboard operating aircraft. 
The GUSs and backup GUSs were part of the ground 
system developments associated with the GCCS contract. 

The WAAS GCCS contract was awarded to Lockheed 
Martin, as illustrated in Figure 4. Lockheed Martin was 


responsible for building the two payloads and was also 
responsible for securing the host accommodations for those 
payloads. The contract included an option for a third 
spacecraft, but this was not exercised. The first host 
spacecraft is Galaxy 15, which is owned and operated by 
Intelsat, was built by Orbital Sciences, and was launched by 
ArianeSpace. Galaxy 15 was undergoing re-work for a new 
business case when Lockheed arranged for WAAS 
integration. The second host spacecraft is Anik FIR, which 
is owned and operated by Telesat, was built by EADS 
Astrium, and was launched by ILS. Lockheed had 
discussions with Telesat for several years, and WAAS 
payload requirements were included in their contract with 
EADS Astrium. The GCCS contract included 10 years of 
operation of the hosted payloads. The payloads are used 
operationally in support of aircraft navigation and the 
contract contains provisions to prevent the L-band hosted 
payloads from being shut off by the spacecraft. 



Figure 4: Primary Actors in WAAS/GCCS Hosted 
Payload Program 


FAA established informal peer to peer teaming 
arrangements in addition to the formal contract structure. 
The informal teaming was credited for part of the program’s 
success. 

WAAS Payload — The WAAS payloads are L-band payloads 
with a mass of about 60 kg, power requirements of about 
300 W, and a 10 year design life. 

Contracting — FAA developed separate contracts between 
FAA and Lockheed Martin (Galaxy 15), and FAA and 
Telesat (Anik Fl-R). FAA required all subcontractor 
contracts and specifications to be delivered to FAA. The 
acquisition required legislative changes in the structure of 
FAA forward financial commitments that are already 
available to NASA and DOD. FAA’s Statements of Work 
and Requests for Proposals were followed by Letter 
Contracts (high level agreements) and finalized in 
Defmitized Contracts. 

Other Notes — The Galaxy 15 spacecraft was carrying one of 
the WAAS/GCCS payloads when it failed on orbit. Due to 
solar activity, the bus stopped responding to commands, 
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although all systems continued functioning. [5] The bus 
failure is unrelated to the hosted payload, and in fact the 
hosted payload continued operating after control of the 
spacecraft was lost. Such energetic particle damage could 
occur on any space mission, whether it carries a hosted 
payload or not. For example, in September, 2008 a DoD 
spacecraft, the Defense Support Program Flight 23 (DSP- 
23) failed in a similar uncontrolled manner to Galaxy 15. 
Like Galaxy 15, DSP-23 drifted through the orbital slots 
around GEO. DSP-23 was a dedicated DoD spacecraft, 
acquired with military review and quality assurance 
processes. [6] Such incidents are not generally considered 
any more of a risk for a hosted payload program than for a 
payload on a dedicated USG spacecraft. 

Takeaway Lessons — FAA modified their contracts to 
Indefinite Delivery Indefinite Quantity (IDIQ) contracts for 
up to 3 WAAS payloads with hosting arrangements. These 
IDIQ contracts provided an additional flight opportunity 
without repeating the lengthy solicitation and contracting 
process. 

AIS: Automatic Identification System Demonstration 

The AIS hosted payload was a program sponsored by the 
USCG to demonstrate the concept of receiving and 
retransmitting AIS signals from orbit. This LEO 
demonstration mission was part of the larger Nationwide 
AIS (NAIS) system being developed by USCG for the 
Department of Homeland Security. NAIS allows the 
collection of AIS signals from ships up to 2000 nautical 
miles offshore for identification and tracking. 



Figure 5: Primary Actors in the AIS Hosted Payload 
Program 


The AIS hosted payload began with a Firm, Fixed-Price 
(FFP) contract awarded to ORBCOMM on May 20, 2004, 
for $7.8M. ORBCOMM was responsible for building the 
AIS payload, integrating it with the bus and primary 
payload, launching the Coast Guard Demonstration 
Spacecraft (CDS), and performing on orbit operations. As 
illustrated in Figure 5, ORBCOMM subcontracted the bus 
manufacturing, spacecraft integration, and launch to 
Orbitale Hochtechnologie Bremen - System (OHB-System, 
or OHB). OHB handled integration and testing of the 
payload and bus, but subcontracted to Polyot for the 


manufacturing of the bus and the launch operations. [7, 8] 
ORBCOMM subcontracted with Orbital Sciences to build 
both the primary payload and the AIS payload. 
ORBCOMM operated the spacecraft and its payloads, and 
provided the downlinked AIS data to USCG. ORBCOMM 
was also able to market the AIS data to other buyers if they 
were approved by USCG. [9] The AIS hosted payload was 
developed along with the primary payload in about one 
year, and it took three months to complete integration with 
the bus. [10] 

The AIS demonstration program experienced several delays. 
First, there were some technical issues associated with the 
primary payload that delayed the launch of the spacecraft. 
The delays caused by the loss of the intended launch vehicle 
were more significant. The CDS was intended to share this 
launch vehicle with a Russian spacecraft. However, the 
Russian Ministry of Defense objected to the USCG payload 
and the CDS was removed from that launch. [7, 11] 
Subsequently, it took several years to find another launch. 
In the end ORBCOMM launched the CDS along with five 
other AlS-equipped ORBCOMM spacecraft in June, 2008 
on a Russian Cosmos launch vehicle. 

The other five ORBCOMM spacecraft, referred to as Quick 
Launch spacecraft, also included AIS secondary payloads 
and were built in parallel with the CDS. The Quick Launch 
spacecraft were scheduled to launch a year or more after the 
CDS, but the launch delays led to all six spacecraft 
launching on a single vehicle. The combined launch 
represented a potential risk for ORBCOMM because the 
AIS concept had not yet been proven. However, the joint 
launch provided a strong start on marketing AIS data 
services. [7, 11] Ultimately, this arrangement proved to be 
beneficial to ORBCOMM, because the CDS failed in 
August, 2009. The USCG had contracted for the capability 
to receive and transmit AIS data, and ORBCOMM was able 
to supply that capability using the Quick Launch spacecraft 
instead. 

The hosted payload program was beneficial for 
ORBCOMM because it created a new market for the sale of 
AIS data services. USCG initiated the AIS data market and 
can now buy AIS data services commercially. The AIS data 
is provided through existing commercial infrastructure, so 
the USCG does not have to maintain or upgrade the space or 
ground systems associated with the AIS capability. [1 1] AIS 
payloads are now used internationally to monitor 
shipping. [8] 

AIS Payload — The AIS demonstration payload was a Very 
High Frequency (VHF) receiver/transmitter with a mass of 
about 3 kg and power requirement of about 8 W. Data was 
downlinked at a rate of 10 kbps and minimal commanding 
was required. The only modification required to the 
existing ORBCOMM bus design to accommodate the AIS 
payload was an extension of the antenna. [10] USCG 
provided performance specifications for the capability, but 
did not design or develop the payload. USCG attended 
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regular design reviews, such as a Preliminary Design 
Review (PDR) and Critical Design Review (CDR), but their 
oversight was limited. [1 1] 

Contracting — The contract between USCG and 

ORB COMM covered the payload design, build, integration, 
test, and launch along with on orbit checkout and one year 
of operations. This contract also included an optional one- 
year extension for operations, which the USCG 
exercised.[ll] ORBCOMM owned the CDS spacecraft and 
the AIS hosted payload, and USCG had no financial liability 
when the CDS bus failed. [1 1] 

The contract did not specifically cover termination liability. 
USCG was obligated to pay for all work up to a termination 
for convenience. The contract also did not cover insurance, 
but ORBCOMM insured themselves. [7, 1 1] 

Since ORBCOMM was responsible for the primary and 
hosted payloads along with the bus, there were no issues 
specifically associated with the hosted payload damaging or 
delaying the primary payload or spacecraft, or vice 
versa. [ii] 

Takeaway Lessons — Both the USCG and ORBCOMM 
benefited from the new market for AIS data services that 
was created through the hosted payload program. The 
contract was simplified by having a single, responsible 
prime contractor. 

Restricting the operation period of the demonstration 
satellite to one year with a one year optional extension was 
later viewed as a limitation. It is recommended that for any 
potential extensions, options be built into the contract for 
each year of extension beyond the original baseline 
duration. [11] 

Issues with foreign governments are potential concerns for 
any hosted payload program due to the multinational 
composition of commercial satellite companies and launch 
service providers. 

IRIS: Internet Router In Space 

The IRIS hosted payload program is a DoD-funded program 
executed by a partnership between Intelsat and Cisco to 
provide Cisco routing capabilities on orbit. IRIS allows 
routing to be performed on an operational spacecraft rather 
than bringing the data stream to the ground to perform the 
routing function. The IRIS payload is hosted by Intelsat 14, 
which was launched in November 2009. [12, 13] 

The Intelsat/Cisco team developed the payload in response 
to a RFP for space-based Internet routing capabilities 
published by the United States Strategic Command as a 
Joint Capability Technology Demonstration (JCTD) project. 
The proposal award was for $12.1M, but Cisco also 
contributed internal research and development funding to 
the effort. The award covered development of the payload 


and the first 90 days of operations. Further operational time 
up to the 10-year expected lifetime of the payload is to be 
paid from user fees. 



Figure 6: Primary Actors in the IRIS Program 


The contract with DoD was awarded in April 2007. The 
IRIS payload was delivered to the commercial host for 
integration 6 to 7 months before the planned launch in the 
first quarter of 2009. The team subcontracted with ViaSat 
for the software defined radio (SDR) portion of IRIS and 
with SEAKR for packaging the payload electronics. The 
Intelsat commercial host spacecraft was a Loral 1300 bus, 
manufactured by Space Systems/Loral. The relationships 
between the various actors are illustrated in Figure 6. After 
the successful launch and 90-day checkout on orbit, the 
operator is now soliciting users for the payload as regular 
commercial customers. 

IRIS Payload — The IRIS payload is a Cisco Internet router 
that has been packaged for space. In place of the normal 
baseband local area network connection, the IRIS payload 
interacts with the user via a SDR that can support an 
aggregate data throughput of 60 Mbps to users separated by 
intercontinental distances. The payload has a volume of 
0.127 m 3 , a mass of 90kg, and uses 250 W of power. The 
control of the payload from the ground is accomplished via 
background command and telemetry links, much as is done 
with the router in its ground configuration. 

Contracting — Cisco is not normally a builder of space- 
qualified electronics and they elected to use subcontractors 
for the execution of the space hardware. ViaSat provided 
the SDR based on their commercial line. SEAKR provided 
the integrated payload package. 

Takeaway Lessons — Despite having no prior experience 
with space electronics, Cisco found that their commercial 
development and test processes were competitive with 
others in the aerospace industry. As such, they did not need 
to modify their processes to develop a space-capable version 
of their existing router. [12] 

A useful step undertaken by the IRIS team was to develop a 
mass model of the payload. The mass model served to 
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reduce risk since it could be flown instead if the IRIS 
payload was unable to meet the delivery schedule, without 
requiring any adjustments to the rest of the commercial 
mission. [12] 

CHIRP: Commercially Hosted Infrared Payload 

The CHIRP flight demonstration program is a risk reduction 
measure for the USAF Third Generation Infrared 
Surveillance (3GIRS) system. The hosted payload is an on 
orbit test of the capability of a wide field-of-view (WFOV) 
IR staring sensor from GEO, which will increase the 
Technology Readiness Level of this type of sensor. [14] 

In December, 2005, the USAF received new direction for its 
space-based infrared system, which was tasked to SMC. 
SMC developed requirements for a next-generation missile 
warning system and selected WFOV sensors as the most 
promising technology. SMC then tasked the Air Force 
Research Laboratory (AFRL) to develop this technology, 
through competitive processes. Several companies 
developed sensor designs, including SAIC, whose design 
consisted of four /4-Earth staring sensors. [1] 

In January, 2008, the government received an unsolicited 
proposal from AGS for a “Commercially Hosted Infrared 
Payload.” The proposed hosted payload program would 
host one of SAIC’s /4-Earth sensors with the remaining 
capacity on the nadir deck of an existing communications 
spacecraft, which AGS had scheduled for launch to GEO in 
2010. By June, 2008, a FFP, sole source contract had been 
awarded to AGS for $65M to complete the CHIRP 
technology demonstration as outlined in the AGS proposal. 

Figure 7 illustrates the contractor relationships and lines of 
communication of the CHIRP program. A simpler structure 
would be more desirable, but the unsolicited proposal from 
AGS could not be modified without re-competing it. AGS’s 
parent company, SES, had an existing order with Orbital 
Sciences for three spacecraft (OS1, OS2, and OS3).[14] 
AGS was to manage the program and provide one year of 
operations for CHIRP. AGS contracted Orbital Sciences to 
modify the OS2 spacecraft with a Secondary Payload 
Interface (SPI) to accommodate the hosted payload. Orbital 
Sciences was also responsible for developing the CHIRP 
Mission Operations Center. Orbital Sciences subcontracted 
the payload, integration, and CHIRP Mission Analysis 
Center developments to SAIC. [15] However, in order to 
protect proprietary information and avoid any contract 
issues, the SAIC team responsible for the CHIRP payload 
was internally firewalled from the SAIC team that had been 
developing the /4-Earth ground sensors under the existing 
contract with AFRL. Communications between AFRL and 
AGS were limited to the status of the payload and payload 
tests. Additionally, communications between AGS, OSC, 
and SAIC were limited to a single contact person at each 
organization. The situation created a limited flow of 
information between all parties, including to SMC. The 
restricted information flow created issues for the CHIRP 


program. 



Figure 7: Primary Actors in the CHIRP Program 


The original CHIRP schedule had a launch window from 
May to September, 2010. The delivery of the final CHIRP 
sensor was over a year late. This delay led to further delays 
as SMC and AGS renegotiated the future of the CHIRP 
program. [15, 16] In the end, AGS switched the launches of 
OS2 and OS3 to accommodate the delays and enable the 
program to continue (at additional cost to SMC). The 
CHIRP payload was delivered to Orbital Sciences during 
the summer of 2010, with the launch currently planned for 
the third quarter of 20 1 1 . [16] 

CHIRP Payload — The CHIRP payload is similar in mass 
and complexity to the types of sensors that NASA might fly 
for science missions, making the program particularly 
interesting for the purposes of this study. The payload mass 
of 115 kg offsets about three years of stationkeeping 
propellant from the spacecraft. The revenue for those three 
years is accounted for in the contract cost.[l, 15] The 
payload has a power requirement of 275 W, a maximum 
downlink capability of 70 Mbps, and a commanding rate of 
5 Mbps. [16, 17] CHIRP also includes two cryocoolers and 
a radiation shield to handle the high temperature 
environment of the nadir deck. At the beginning of the 
CHIRP program, the sensor existed as a ground based 
sensor that required some modifications for spaceflight. 
The required modifications included adding the radiation 
shield as well as a baffle cover. The cover serves as 
contamination control to protect the sensor from the 
outgassing of the rest of the spacecraft during the initial 
checkout period. [15, 17] 

The payload is connected to the bus by the SPI, a system 
which encrypts the sensor data before it is passed to the 
spacecraft bus for downlink. This system ensures that no 
unencrypted data ever exists on the commercial 
spacecraft. [15, 16] The SPI is a National Security Agency- 
approved encryption device. The encrypted data is 
downlinked through a leased commercial transponder. 
SMC also paid for additional transponders to be turned off, 
to offset power required for the CHIRP payload. These 
transponders may be activated and used for commercial 
services after the CHIRP program has been successfully 
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completed. AGS asserts that on a larger bus, power would 
not be an issue and that they could have redesigned the 
power system with more time in the planning stages. [16] 

As a hosted payload, CHIRP is under a constraint to do no 
harm to the primary payload or the host spacecraft. This 
paradigm led to some modifications that were undesirable 
from SMC’s perspective. These modifications include a 
fused power system that will permanently cut off the 
CHIRP payload if it draws too much power. The payload 
baffle was cut to support the communication satellite’s omni 
antenna view, resulting in a slightly larger solar exclusion 
angle for the IR sensor. The baffle cutting was a result of 
the limited flow of engineering data from SAIC and Orbital 
Sciences. The lack of engineering data also led to a late 
change in the physical mounting of CHIRP to the nadir 
deck. Originally the payload was to mount directly to the 
deck, but was modified to include mounting legs. The legs 
contributed to issues during vibration testing. 

The USAF program managers were involved in 
development, integration, and testing, but only for 
observation. AGS did the quality assurance, providing the 
USAF with insight, but not oversight. [16] 

Contracting — Contract payments were agreed to be 80% 
scheduled commercial payments and 20% incentive 
payments for successful completion of certain milestones. 
The CHIRP payment schedule was set up so that if SMC 
canceled the program at any time, AGS would always have 
been paid for all work completed. [18] The contract covers 
termination for convenience with limits on the associated 
costs.[l] 

The CHIRP contract includes a “shared risk” clause. This 
clause means that USG and AGS shared the risk for missing 
the original launch window. Specifically, the clause states 
that the CHIRP launch is at “no fault” to the contractor team 
or government. The clause limits the financial 
responsibility of both parties and this clarity is important for 
avoiding lengthy renegotiations and getting the program 
back on track after a delay. [1] A limitation of the shared 
risk clause was that it did not cover what would happen in 
the event of additional delays after the May-Sept launch 
window had already been missed. The CHIRP sensor was 
delivered late and USG took an off-ramp for a delayed 
launch, which led to an engineering change proposal and a 
period of renegotiation. [16] 

The CHIRP payload was provided as Government 
Furnished Equipment (GFE) and AGS was responsible for 
integrating it with the rest of the spacecraft. Therefore, 
AGS would not be paid damages if the CHIRP payload 
damaged the primary payload or the spacecraft. [15, 19] 
AGS included additional insurance premiums in their 
proposal to account for this possibility. [16] 

CHIRP was awarded as a sole source contract, based 
primarily on the justification that AGS was the only 


commercial owner/operator launching to the desired 
location in the desired timeframe.[l] 

The CHIRP contract included a clause that in the event of a 
congressional continuing resolution, USG would make “best 
efforts” to obligate funds in accordance with the agreed- 
upon payment schedule, including event-based payments. 
Once current year funds were released, USG would obligate 
funds against any unfunded commercial obligations. [14] 

During the period of time between the unsolicited proposal 
and the contract award, the spacecraft’s designated orbit 
location was changed from 79 West to 103 West. Since 
contract award, the orbit location has changed again, to 87 
West. The CHIRP team elected to continue the program 
with the new location, rather than take the option to 
terminate the program. [1, 16] 

Takeaway Lessons — It was suggested by those involved in 
the CHIRP program that hosted payloads should be 
developed, tested, and built before contracting to put them 
into orbit. [14, 15] It was also suggested to have a single 
contractor who is responsible for building, integrating, 
launching, and operating the payload. [15] 

Upfront systems engineering is important to avoid later 
technical issues, which cause costly modifications and 
schedule delays. The contract should include spacecraft 
specifications/data/models as contract deliverables. [14] 

ADF UHF: Australian Defence Force UHF Payload 

The ADF UHF payload is presently under construction for a 
launch in mid 2012 with an expected lifetime of 15 years. 
The UHF payload will comprise a significant portion of the 
Intelsat-22 spacecraft. The payload design is based on an 
existing US DoD communications payload that the ADF 
currently uses as part of a sharing agreement. The ADF 
awarded the contract to Intelsat in April, 2009. As 
illustrated in Figure 8, Intelsat subcontracted with Boeing to 
provide both the spacecraft bus and the UHF hosted 
payload. The UHF payload will provide military 
communications for the ADF and allied forces, but will be 
controlled by the ADF. The contract award was for $167M 
and includes the payload, launch, and costs for 15 years of 
operation. [20] 

UHF Payload — The UHF payload is about 20% of the total 
payload capacity of the Intelsat spacecraft. It has a volume 
of 8 m 3 , a mass of 450 kg, and a 2 kW power requirement. 
The actual payload is based on existing military 
communications capabilities built by Boeing for the US 
DoD. 

Contracting — The ADF indicated that there were many 
contracting issues due to the differences between nominal 
defense procurement and a commercial procurement. The 
ADF stated that these were solved through detailed and 
pragmatic negotiations on both sides. The ADF retained a 
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special contracting lawyer to work the specific contracting 
details that were outside the normal ADF procurement 
process. [20] 



Figure 8: Primary Actors in ADF UHF payload program 

The key contracting issues for the ADF UHF payload 
revolved around which party assumes which risks and when 
those risks come into play. Most of these issues were 
resolved through the use of insurance. For example, the 
insurance in the contract covers launch plus one year of 
services, beyond which the service fee ceases if the payload 
is shut down. Termination conditions were also negotiated 
into the contract and covered by insurance. 

The contract allows some amount of negotiation of the 
specific orbital arc location, provided that the ADF mission 
needs are still met. 

Takeaway Lessons — The ADF team identified several items 
that have contributed to the success of their hosted payload 
program to date, including: 

• Having a single contractor for both the spacecraft 
bus and the hosted payload developments 

• Having a well-understood payload design that has 
been operated in orbit before 

• Using insurance to cover performance issues and 
schedule delays 

3. Results and Discussion 

Throughout the course of the hosted payload study, the team 
met with employees of satellite manufacturers, satellite 
owner/operators, and others involved in hosted payload 
programs. These meetings occurred at conferences, 
working groups, and in some cases, site visits with the 
teams. Through these contacts, the study team was able to 
acquire copies of the contracts from the WAAS, AIS, and 
CHIRP hosted payload programs, although in some cases 
certain commercially sensitive data was withheld or 
redacted. 


Lessons Learned 

Contracting Structures — In most of the hosted payload 
programs studied, the contract was signed between the USG 
customer and a single contractor, who was responsible for 
all aspects of the contract. In many cases, this prime 
contractor was the spacecraft owner, although in the case of 
WAAS it was with the payload provider. For WAAS, 
Lockheed Martin treated each of the WAAS hosting 
accommodations as a contract with a single spacecraft 
owner for the spacecraft and launch. Contracting with the 
spacecraft owners has been the preferred method of setting 
up a hosted payload program. Having a single prime 
contract was identified as a key lesson from most of these 
past programs. 

CHIRP is the exception to the relatively simple contract 
structures of the other programs. Its more complex program 
structure was due to both the nature of the unsolicited 
proposal from AGS and the existing contract and 
relationships between SMC, AFRL, and SAIC. The more 
complex contracting organization of the CHIRP program 
created several issues related to program management and 
communication of technical data, which ultimately resulted 
in program delays. 

Contract Terms and Conditions — From recent hosted 
payload programs, several identified items may be 
addressed in the terms and conditions of a hosted payload 
contract. These items are described below and, when 
available, the methods used to handle that item in the 
existing contracts are discussed. Additional detail about 
these and other contract terms and conditions can be found 
in the Hosted Payload Guidebook developed by Futron 
Corporation as a parallel to this hosted payload study. [21] 
Familiarity with potential issues and how to negotiate them 
is key for any future hosted payload contracts. 

The schedule for a hosted payload program is critical, so the 
contract should address what happens in the event of a 
launch delay, payload delay, or a missed launch. Methods 
of addressing these events varied across the different 
programs and include program off-ramps built into the 
contract, using insurance as mitigation, or assigning penalty 
payments. The CHIRP shared risk clause provided for no 
fault to either party, although it only covered delays from 
the original launch window. Contractually addressing a 
delay or missed launch avoids difficult and costly 
renegotiation periods and keeps the program moving 
forward. 

A hosted payload contract should also include mitigations or 
responses to a failed launch, hosted payload failure, or host 
satellite failure. If the contractor is responsible for 
developing and integrating the payload they generally bear 
the responsibility for any failures. In the case of a GFE 
payload, the customer would generally be responsible if 
their payload were to damage the primary payload or 
spacecraft bus. Again, in some cases failures were dealt 
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with using insurance, and in others there were penalties for 
various types of failures. 

In the event that the satellite operator changes the 
spacecraft’s orbit location either before or after launch, the 
customer requires an option to continue the program at the 
new location or terminate the program if the new location is 
unacceptable. 

Contracts generally provided language covering various 
types of termination and the associated termination liability. 
In the case of CHIRP, the payment schedule was set up so 
that AGS was always paid up for their work on the program 
so there was no additional liability. 

Program Schedules and Delays — From Figure 9, it is clear 
that the hosted payload program schedules generally ranged 
from 2 to 4 years. For some programs, this short schedule 
was possible because the communications payload being 
hosted was not complex or was of a fairly standard design. 
In the case of the CHIRP sensor, the schedule was possible 
because the ground version of the sensor had already been 
under development for eighteen months before the hosting 
contract was awarded. To host a NASA sensor, a key lesson 
is that the payload development should be at a CDR-level 
prior to awarding a hosting contract. 

Many programs experience schedule delays, so it is no 
surprise that the hosted payload programs shown in Figure 9 
display them as well. Most also included some combination 
of delay in payload development and delays in the launch. 
The AIS launch delay, as described previously, was 
significant and was an issue associated with a foreign 
government objection, and not a technical payload issue. 
The CHIRP sensor shows the longest development delay, 
despite the prior development of the ground sensor. This 
development delay is attributed more to the limited flow of 
data across the program than the complexity of the sensor or 
integration itself. The ADF hosted payload program is not 
included in this figure since it is still early in the program 
execution. 


□ Time to Payload Delivery (Planned) DTime to Launch (Planned) 

Time To Payload Delivery (Actual) ■ Time to Launch (Actual) 



Figure 9: Planned and Actual Hosted Payload Program 
Durations 

Cost Model 

From the information available about the prices of past 


programs, the study team attempted to develop parametric 
equations or response surfaces that could be used to estimate 
the prices of future hosted payload programs. The resulting 
parametric model may be viewed as a rough order of 
magnitude (ROM) estimate at best, since it is based on only 
a handful of data points, some of which were estimated by 
the study team. The actual cost data used to generate the 
model cannot be displayed here since it is sensitive to the 
commercial entities involved in the programs. 

The original approach was to plot total program cost against 
a number of payload parameters, program parameters, and 
combinations of the two. The cost for only the hosting 
accommodation portion of the program was also plotted 
against the same sets of parameters. The hosting cost 
includes the cost for interface development and integration 
of the payload onto the spacecraft, as well as any fees to the 
owner or spacecraft provider. The hosting cost does not 
include costs associated with operations, data processing, 
ground system development, or development/modification 
of the hosted payload itself. 

Most of the resulting curve fits or response surfaces did not 
indicate any useful trends. Ultimately, the model which 
made the most sense was the simple linear fit to the plot of 
hosting accommodation cost versus hosted payload mass, 
which is shown in Figure 10. Fees for on-orbit operation of 
the hosted payload and data transmission are not included in 
Figure 10. 



Figure 10: Hosting Cost vs. Hosted Payload Mass 

Red line indicates a notional 50 kg NASA science 
payload 


The model in Figure 10 indicates a minimum cost of $6.6M 
for a contractor to consider hosting a payload. A minimum 
cost for consideration of hosting was expected. However, 
since each payload varies according to the specific business 
case associated with the host spacecraft, it is not clear that 
the indicated value is the correct value of that minimum. 
The model also indicates that the payload hosting costs 
increase by about $0.1 75M per kilogram. The result is that 
the model estimates a cost of $15M to host a notional 50 kg 
payload. It is logical that mass would be a cost driver and 
power would not. Due to the degradation of power 
generation from beginning to end of life, the host satellites 
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will always have some excess power available after launch 
for a hosted payload to use. 

One limitation of this cost model is that it mixes hosted 
payloads that are, from a commercial perspective, familiar 
communications payloads with unfamiliar payloads such as 
Earth-observing sensors. The lack of familiarity generally 
requires more careful examination of interfaces between the 
payload and the host spacecraft and increases the costs of 
integration and test. 

The model may oversimplify any unusual circumstances 
associated with specific payloads including high payload 
power requirements, challenging thermal requirements, or 
specific contract terms and conditions that drove the price. 



Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 


Figure 11: Sample Hosted Payload Payment Profiles 

With the limited data available, the team also developed an 
average cost profile from hosting contract award to launch. 
Figure 11 shows the resulting average of three payment 
profiles, which were each scaled to two year durations and 
plotted as a percentage of all payments up to launch. Again, 
actual payments and dates are sensitive and therefore not 
included in this paper. The average payment profile, shown 
as a dotted line, indicates an initial payment of -25% up 
front, followed by a steady payment rate afterwards. 

4. Conclusion 

Hosted payload programs are likely to continue to be used 
to satisfy niche needs for USG customers. The lessons from 
past programs gathered in this paper should serve to inform 
future program planning. The cost model developed can 
provide ROM estimates for hosted payload accommodation 
prices to further aid in planning. 

High-level recommendations for future programs include: 

• Develop complex payloads to a CDR level prior to 
contracting for hosting accommodations 

• Simplify the program organization and lines of 
communication as much as possible 

• Treat the contract as the procurement of a commercial 
service rather than a development task 

• Address typical project events in the initial contract 

negotiations to avoid costly contract 

changes/renegotiations later in the program 


The hosted payload projects that were studied did not 
generally see themselves as models of sustainable 
acquisition. In most cases, the projects captured 
opportunities that were less than optimal, but allowed the 
projects to proceed. 

NASA and other USG agencies are capable of executing 
certain types of missions using the commercially hosted 
payload approach with its shorter schedules and lower cost, 
without sacrificing the quality of the returned data. 

Within the US Government, the FAA, USCG, USAF, and 
DoD have already completed or are currently executing 
commercially hosted payload programs. Beyond that, the 
US DoD, through NS SO, is taking the necessary steps to 
make commercially hosted payloads a more commonly 
employed solution for satisfying certain aspects of their 
missions. NASA and other USG organizations may expand 
the use of hosted payloads for achieving appropriate aspects 
of their missions 
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Third Generation Infrared Surveillance 
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Australian Defence Force 

AEHF 

Advanced Extremely High Frequency 

AFRL 

Air Force Research Laboratory 

AGS 

Americom Government Services 

AIS 

Automatic Identification System 

AO 

Announcement of Opportunity 

CDR 

Critical Design Review 

CDS 

Coast Guard Demonstration Spacecraft 

CHIRP 

Commercially Hosted Infrared Payload 

DoD 

Department of Defense 

DSP 

Defense Support Program 

FAA 

Federal Aviation Administration 

FFP 

Firm, Fixed Price 

FOV 
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GFE 

Government Furnished Equipment 
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and Disk 

GPS 

Global Positioning System 
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GEO Uplink Station 

I&T 

Integration and Test 

IDIQ 

Indefinite Delivery, Indefinite Quantity 

IP 

Internet Protocol 

IR 
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IRIS 

Internet Routing In Space 
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LEO 

Low Earth Orbit 

NAIS 

Nationwide Automatic Identification 
System 

NASA 

National Aeronautics and Space 

Administration 

NPOESS 

National Polar-orbiting Operational 

Environmental Satellite System 

NSSO 

National Security Space Office 

OHB 

Orbitale Hochtechnologie Bremen System 

PDR 

Preliminary Design Review 

PI 

Principal Investigator 

RFP 

Request for Proposal 

ROM 

Rough Order of Magnitude 

SBIRS 

Space Based Infrared System 

SDR 

Software Defined Radio 

SMC 

Space and Missile Systems Center 

SMEX 

Small Explorers 

SPI 

Secondary Payload Interface 

STEM 

Science, Technology, Engineering, and 
Mathematics 

UHF 

Ultra High Frequency 

USAF 

United States Air Force 

USCG 

United States Coast Guard 

USG 

United States Government 

VHF 

Very High Frequency 

WAAS 

Wide Area Augmentation System 

WFOV 

Wide Field of View 
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